Sort published samples explicitly instead of relying on readdir order - #28
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Nothing in compile.ts sorted. Providers, versions and topics were emitted in `fs.readdir` order, which is filesystem-dependent: APFS returns entries sorted, ext4 with dir_index returns them in hash order. The published files look alphabetical today only because they were last built on a Mac. There is no CI in this repo and `public/` is gitignored, so the order consumers receive depends on whose machine ran the build. Providers, versions and topics are now sorted explicitly. Topics are sorted by the topic they publish, not by filename. Those are different strings — `orders.create.json` publishes `orders/create` — and the topic is what consumers see. They happen to sort identically today because `.` and `/` are adjacent in ASCII with nothing between them, but that is a coincidence, not a reason to sort the wrong key. Also writes each version file once rather than once per topic. The write was inside the topic loop, so shopify/2026-07 was written 217 times per build, each time with a progressively more complete object. Output is byte-identical to the previous build across all 112 providers, and two consecutive runs now produce identical bytes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019pce9oHWGjdwHsJNya1ovP
leggetter
force-pushed
the
fix/deterministic-sample-order
branch
from
August 11, 2026 09:18
f084bc3 to
4019a43
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
compile.tsnever sorted anything. Providers, versions and topics were emitted infs.readdirorder, which is filesystem-dependent — APFS returns entries sorted, ext4 withdir_indexreturns them in hash order. The published files look alphabetical today only because they were last built on a Mac.There's no CI in this repo and
public/is gitignored, so the order consumers receive currently depends on whose machine ranyarn compile. Providers, versions and topics are now sorted explicitly.Topics sort by topic, not by filename
Those are different strings:
orders.create.jsonpublishes the topicorders/create, and the topic is what consumers see. They happen to sort identically today because.and/are adjacent in ASCII with nothing between them — a coincidence, not a reason to sort the wrong key. Collecting the parsed topics first and sorting by the published key removes the dependency on that.Also: one write per version instead of one per topic
The
writeFilesat inside the topic loop, so each version file was rewritten once per sample, each time with a progressively more complete object.shopify/2026-07was written 217 times per build. It's now written once, after the loop.Testing
yarn compileoutput is byte-identical to the previous build across all 112 providers — same content, same key order, verified forproviders.jsonand a version file. Two consecutive runs now produce identical bytes (md5match), which wasn't previously guaranteed across machines.Pairs with a Console change that orders the provider list by inbound webhook volume and then alphabetically; this PR is what makes the alphabetical half of that dependable.
🤖 Generated with Claude Code
https://claude.ai/code/session_019pce9oHWGjdwHsJNya1ovP